The KDE development team is working hard on the KDE 4 platform. KDE 4 will include many exciting new technologies which will greatly enhance the functionality of KDE. One of these new technologies is Decibel. We would like to give you an idea of what Decibel is all about.
In putting this article together, the KDE promotional community was able to get most of the information from the lead developer of Decibel, Tobias Hunger. Tobias lives in Germany and studied Computer Engineering at the University of Kaiserslautern. Upon graduating, he found a job as a consultant for a small company specializing in systems management. Currently, he is employed as a software developer for basysKom GmbH.
This article is part one of a four part series about Decibel. In part one, we would like to provide a general overview of Decibel. Part two will define several terms related to Decibel. Benefits for developers will be covered in part three. Finally, part four will discuss benefits for users.
People use their computers to communicate with others. Usually, they want to communicate as close to real-time as possible. Email, instant messaging, and Voice over IP (VoIP), are some of the different ways people communicate using their computers. Each of these has its strengths and weaknesses. Ironically, each of these means of communication do not talk very well with other means of communication.
This is where Decibel comes in. Decibel is a service, not an application. The goal of Decibel is to create a bridge between different communication technologies. Decibel will make it easy to integrate real-time communication technologies into applications, Tobias says. Decibel provides a central storage place for settings of real-time communications. This will allow one communication application (say, email) to talk to another communication application (say, instant messaging) without having to learn a new language.
However, Decibel is not going to become yet another isolated box dealing only with communication. There are at least two ways Decibel will be able to connect to technologies and applications not normally associated with communication. Because Decibel allows programs in general to talk to each other in a more streamlined manner, programs that are not related to communication can also take advantage of this technology. For instance, document editors (such as word processors or graphics editors) could use this technology to allow better collaborative editing.
Also, Decibel is being developed to integrate with other KDE technologies. For instance, Phonon is a KDE technology that deals with integrating multimedia programs and services. It is possible for Decibel to work with Phonon in situations such as encoding and decoding voice data during a VoIP conversation.
In part two of this series on Decibel, we will define some terms to help further enhance your understanding of Decibel. In the final two sections, we describe potential benefits for both users and developers, and provide information on how to get involved with the Decibel project. The goals of the Decibel team are wide-ranging and forward-thinking. They have done an excellent job of specifying their vision. However, they are still in the beginning stages of reaching their goals. Much work needs to be done. The Decibel team would appreciate any help they can get.
Comments
Personally, I think Decibel sounds a bit scary. I'm not big on integration myself, and that's what it sounds like to me. That said, KDE appears to have a much better approach than Microsoft (sorry, but I'm both a KDE and Windows fanatic ;-) ). For example, Microsoft chose to integrate MSN Spaces, Microsoft's blogging site, with MSN Messenger. Now, I absolutely despise MSN Spaces, and have no official way of removing the 'functionality' from their Messenger, or associating with a different blogging site.
Either way, I'm still very interested to see it in action. You guys have proved to be capable of making some very cool stuff. I consider KDE 3.4 to already be superior to the Windows desktop environment, and that definitely says something to me (although some people might take it the wrong way).
On an unrelated note, how is KDE4 moving along, if I may ask? On Slashdot, I read a random commenter saying saying something along the lines of it being mostly ideas, but little code. Are you still on track for a final release in the first half of this year? That's what I read, anyway. 2007 looks like it'll be a great year for Linux-based OSes!
(Oh, and kudos to you for a commenting system that doesn't require an e-mail address. Nice CAPTCHA, too!)
~ random Kubuntu n00b
I see Decibel the same way as DirectX is: a framework that gives application writer the *possibility* to use certain technologies without having to deal with their details in each single application. Application writer may simply ignore some of Decibel, that would not harm.
KDE4 is indeed a lot of ideas, with the subtle difference that you can check them out, compile and run them on your computer :-)
It's not gonna be like DirectX at all, do you even know what DirectX is? Think SDL, this is not a programming interface, it is indeed a service based integration. Just like Phonon is, you add Phonon to your application and your application will use any feature you define in Phonon, for example, you can use Xine engine or Gstreamer, or just like a demonstration in Phonon article in here that shows that we can change the sound devices on the fly.
If for example Kopete would implement Decibel, then you'll have different things to it, there's houston that's a connection manager, I.E: You add a plugin for a certain protocol, and Kopete will be able to connect to this protocol. From what I understand, it can already do that (Decibel).
In fact PAF was not completely wrong.
For example DirectShow allow any media player to use different filters (codec) without having to make specific code. And as AvKode is the phonon backend for FFMpeg, FFDShow is a DirectShow backend for FFMpeg.
So even if phonon has more features, it is comparable to DirectShow.
So please don't ask question like "do you even know what DirectX is?", if you don't know the answer.
Btw, many video gamers confuse DirectX with Direct3D. Direct3D is only a part of DirectX.
> Think SDL, this is not a programming interface
> If for example Kopete would implement Decibel
How can one implement something that is not even an interface ? What I meant is that the application writer needs to make the decision "I want to use online presence in my app", and then gets an API to program against. Now later, when new instant messaging protocols appear, this app will not have to change one iota to accomodate for that new service providing its own online presence.
Same thinking goes for audio/video streaming, PIM info management, and already exists for GUI, kioslaves, kparts, and the list is long...
I think I was not too off the mark :-)
It wasn't off the mark. The guy obviously just had a problem with DirectX being a Microsoft product...so he'd rather choose SDL because it is Open Source. It is your every day example of letting emotion manipulate your thoughts.
FYI, I used to program DirectX...back in DirectX 4 or 5...last time I checked it was at like DirectX 9. Man, I'm getting old.
I don't think this will be the case for KDE4, they are not gonna really make it a part of every application, they are gonna make it an option you can either use or disable, most likely. I don't know though, but I still think Plasma, Phonon, Solid, Decibel, etc... sound really really good, and not overhyped like some thing.
Decibel, it would be awesome for communication, for example, people could write plugins for new protocols and then it would be so easy to implement it in the application. I think we'll finally see some decent VoIP protocols in Kopete, such as real integration with Jingle (Google Talk) and SIP, and who knows, maybe by the time we have KDE4/Decibel out, maybe Skype will finally let people connect to it from other clients, so we'll have a plugin for decibel to connect to Skype. Then Plasma will also allow us to work with Kopete in ways we couldn't think before :) Oh my god... Ok, maybe I'm overhyping this a little.
"I'm not big on integration myself, and that's what it sounds like to me."
Um, what's wrong with integration? Seriously? Should they just keep on re-inventing the wheel? Each and every app does teir own thing, and none of the apps would talk to each other? Is that what you want?
Wow, thanks for all the replies!
And for why I often dislike integration? If you put a lot of not necessarily related functionality in one application (think browsing and BitTorrent), you might end up with a great browser, that has a lousy BitTorrent implementation, and you'll slowly end up with bloatware.
As long as you can still separate the parts, it'll probably not be as much of a problem. If I would've been able to change MSN Messenger's blogging provider as easily as I can change Internet Explorer's search engine, it would not have been a problem. Konqueror's file managing and browsing capabilities don't get in eachother's way either, but that's simply because I think it does a good job at the both of them.
Decibel sounds like it will be a rather modular project, so I'd love to see what will become of it even more.
Another reason is that I like staying on top of certain things myself*. I don't think I'd like to have a list of my contacts, which would automatically select a way of communicating with the person. I like being able to do this manually: open Kopete, check if the person is online, if not, decide to postpone whatever it was I was doing - and not have the operating environment bring up KMail instead, because it would assume it would be the second best option.
*) I am a GUI guy, though.
I guess what I'm trying to say is that you have "combined" integration, like Konqueror, and the linking type of integration, like Internet Explorer's search engines. Both can be good, both can be bad - it has to be done in a non-intrusive way.
"If you put a lot of not necessarily related functionality in one application (think browsing and BitTorrent), you might end up with a great browser, that has a lousy BitTorrent implementation, and you'll slowly end up with bloatware."
Um, that's what would happen with less integration. With integration, you could have separate apps that talk to each other seamlessly. Without integration, every app would have to provide all possible functionality by itself.
And what about likes of Kontact? It has lots of functionality. But that functionality is achieved by integrating separate apps in to one (the separate apps are also available independently). Without such integration, they would have had to write every bit of functionality from scratch. More wasted time, more bloat. Instead of having an app that merely integrates existing apps in to one, they would have had apps for email, calendar etc, but they would also have a PIM-suite that would offer it's similar, yet separate email-app, calendar etc. etc.
KDE is usually not integrating, but it is extending its framework and all apps then use that framework getting the functionality for free.
one can integrate some apps, let say:
- email (kontact) and IM (kopete)
- browser (konq) and torrent (ktorrent)
then the email app would be able to connect with the IM app, and the other way around (same for browser/torrent); or one of the apps completerly integrates the other.
the 'framework sharing' solution is that a framework is created that all apps share (like: anakondi, decibel, kio-slaves, khtml/kjs) then all apps can use the framework; they are really just views of the framework!
so kontact just builds on anakondi and decibel, just like kopete does.
and ktorretn and konqueror just use kio-slaves for sucking in torrents.
that's the kde approach.
"framework sharing" (tm)
Well, if I understand the article correctly, this is an integration project only on service level, not application level, so programmers might make use of it to allow communication things to be seen in final application. For example, your amarok will still be that amarok and not become an application for chatting, you got kopete for that. But amarok can use decibel to easily program a new function that allows you to msg someone on MSN messenger as soon as a certain new song is playing for example.
Well I hope I made my point that it's on service level and not application level.
> But amarok can use decibel to easily program a new function that allows you to msg someone
> on MSN messenger as soon as a certain new song is playing for example.
That's something I'd welcome a lot! Currently Kopete and my client (KMess) need to poll the DCOP calls of Amarok/Kaffeine/Noatun/.. every 4 seconds to get the "now listening to.." information. If the media application can notify the IM-clients instead it would avoid a lot of unneeded DCOP calls (and in the end CPU usage).
Couldn't Amarok/Kaffeine/Noatun/.. just emit a DCOP signal that you could connect to, and save all that polling?
If that was possible.. that would be really sweet! This is currently not the case. There is no way to register for some signal (Observer pattern). The DCOP interfaces of the various applications are not consistent either.
But taking this even further.. IM-clients shouldn't have to know Amarok/Kaffeine/... are media applications. What if an other media player joins the scene? Instead I hope Decibel can offer some generic centralized signal. So when MPlayer/Banshee/xmms/etc.. implement that it could automatically work too.
Currently Kopete and KMess have hard-coded list of calls to make for all different applications. The second part of this source file reveals that: http://kmess.cvs.sourceforge.net/kmess/kmess/kmess/nowlisteningclient.cp...
"There is no way to register for some signal"
This is wrong, you can do this with DCOP. You can even register for a signal with a certain signature (like "started playing of") from any emitter. See http://api.kde.org/3.5-api/kdelibs-apidocs/dcop/html/classDCOPClient.htm...
Or did you mean that Amarok isn't emitting a proper one? Filed a bug/wish report? :)
And a standard DCOP/D-bus interface for media players would be nice, agreed.
The media player should obey to the observer pattern, and just send a signal on it's state changes. It doesn't need to know that it is talking to IM programs :) Loose coupling, no hardcoding.
I think this should be already possible without polling. I only wrote a Lyrics plugin for amarok so far, but I think other plugins work similar. A plugin is a script/program that gets messages from stdin, e.g. the line 'trackChange' to indicate the start of a new track.
So your script reads lines from stdin and waits for that line. When it encounters that line it asks amarok the name and artist of the song by: 'dcop amarok player title' and 'dcop amarok player artist' (or 'dcop amarok player nowPlaying' if you prefer) and send the information to kopete by 'dcop kopete KopeteIface messageContact "$user" "$song"'.
Now put this script into e.g.: ~/.kde/share/apps/amarok/scripts/
and make this file executable.
Instead of using KopeteIface you could use KIMIface and be able to adapt to a different IM app by changing the DCOP name (as long as the other application also implements KIMIface)
So, basically, Decibel is for software what HAL/DBUS is for hardware?
Is it only for audio or are there more applications for it?
No, Decibel is a framework (API) for integrating Communication protocols with KDE applications. Instead of having to program the protocols for every application, you'd have one API that would use DBUS to talk to the Application and back so they can establish connections, start chats, etc....
If we're talking about Amarok here, another thing that would be cool with Decibel is sharing of music directly from amarok to instant messaging. Some sort of Social Network...
I think the name "Decibal" is misleading you into thinking "audio." It seems to be more about instant messaging, e-mail, VoIP and things like that. Probably a better name would be "Kollab" but I think that is taken. Perhaps "Communicate" would be a good name....or should I say "kommunicate"?
ok... i was generally absolutely for all of those changes in KDE4, they sounded ok and practical... but this time i just don't think this is gonna be ok for me. i strongly recommend allowing the user to totally turn off the usage of Decibel by apps.
cheers!
Isn't it a bit early to be judging this?
because?
because i definitely prefer simplicity over all-in-one's. for example i don't like Superkaramba even though i am aware of its functionality - maybe it adds some functionality but intereferes with a native role of a desktop so i don't like it. for me it is easier to navigate in an environment where every program has its own and separate role and i expect my KDE to enable me to switch on/off each function easily. that's why, in a few words. i do not say that this is a bad technology (maybe i just don't realize its advantages) - what i do is just mentioning that i don't think it would be useful _for me personally_. however, it is of course a very early stage of development (or even less: just a description) and surely i will give it a try and then decide what to do. best wishes!
If I understand this right, Decibel is not much more than DCOP/D-BUS. Just a bit of a framework around D-BUS? And KDE3 already uses DCOP heavily, so if you don't want such a functionality, don't use KDE (and don't use GNOME, because those guys already use similar technology).
decibel is more than the communication protocol, it has a daemon (houston) which stores information about on/offline presence and coordinates & communicates settings concerning communation between applications using decibel's protocols.
also, like phonon, decibel will offer some easy-to-use widgets to quickly enable applications to have embedded communicationtools.
decibel sounds simple, but don't underestimate it... :D
I think this has been mentioned before, but I still find it odd: why "Decibel"?
To me it sounds like something to do with sound. Well, you might say that it is; you communicate by talking right? However, what I mean with "sound" is for example music.
If I've understood Decibel right, then something with both connection/communicating would be a more fitting name. Am I wrong?
By the way, thank you for the article.
It is a fitting name. From Wikipedia:
decibel is also considered to be a dimensionless quantity
The bel (symbol B)is mostly used in telecommunication, electronics, and acoustics. Invented by engineers of the Bell Telephone Laboratory to quantify the reduction in audio level over a 1 mile (1.6 km) length of standard telephone cable, it was originally called the transmission unit or TU, but was renamed in 1923 or 1924 in honor of the laboratory's founder and telecommunications pioneer Alexander Graham Bell.
http://en.wikipedia.org/wiki/Decibel
sorry to sound snarky, but if the feature is as "fitting" to KDE, I don't think I really want it :)
Anyway, to me it sounds like Yet Another Communication Layer. What you describe here is an "easier DCOP", another interface that developers will have to add to their programs. Why not spending the effort making DCOP easier...?
1) KDE4 will not use DCOP.
2) DCOP (and D-Bus) is meant for programs on one computer to talk to each other. Decibel is about allowing users on different computers to communicate. That is a pretty different use case! I guess you would not want to communicate with your friends by using predefined "method calls" only;-)
D-BUS is designed to be able to communicate over any kind of socket. Why not make D-BUS able to communicate over a (SSL-)TCP/IP-socket (instead of just over a UNIX-socket)? Or is this what Decibel dose?
decibel doesn't communicate, it uses chatprotocols like msn, irc, voip, email for that. the app just tells decibel 'i want to talk to this user', then decibel looks if that person has a phone, and is available on voip -> calls the user. no phone or not available? let's try chatting. no chatting? mail. etcetera.
it can also tell you if a user is available so the apps don't have to try and figure that out themselves (compare this to phonon), and it can manage meta-settings (like phonon, which can set policies like 'when the phone goes, lower music volume').
> the app just tells decibel 'i want to talk to this user', then decibel looks if that person has a phone, and is available on voip -> calls the user. no phone or not available? let's try chatting. no chatting? mail. etcetera.
I hope you mean giving the user the choice to choose between a number of options to contact someone else. The software can't know about the context. Depending on whom you want when to contact for what reason, you might try possible ways to do so in a different order or even decide to shove it to somewhat later.
There's a helluva lot of reasons to choose between asynchronus/syncronus and voice/video/textual contact methods. SMS has not become so popular for no reason.
A software might well guess, but that's it about it.
well, i think some sane defaults would be nice. the ability to have (configurable) policies like the ones i stated would be nice.
If you really mean the software should decide for the user, I can tell you the software will be pita and you'll earn nothing but complaints.
From a geek pov this is true, from the remaining 98% of users, this is not always true (I mean, that self-deciding software is a pita).
Although I strongly believe that as in usual KDE tradition (almost) everything will be configurable in some way by the end user.
SMS is actually an extremely popular medium in my country. I find it incredibly useful to send an SMS to someone and not interrupt him on what he was doing. He can text back with a reply when he is done.
That is a totally different use case. Same thing goes for IM and chat. Some people prefer an asynchronous communication. Some prefer synchronous ones to make sure they have total attention of the other party.
As already mentioned: DCOP & DBUS are NOT voice nor sound nor voip implementations...
Dbus & Dcop are message bus system for APPLICATIONS --> NOT FOR HUMANS!! xD.
from what I unerstand the layers will be something likde this:
KDE APP
|
|
V
DECIBEL: Which is a service architecture to make chat and phone communication universally available to desktop applications. This part allows you to be creative with the final FUNCTIONALITY of your Product and stop missing time imagining how to do this or this.. in other words --> Think how to USE the PHONE not how to reinvent it.
|
|
V
Phonon: Configurate your sound and multimedia devices easily. Decibel will use it to make the HUMAN <--> Computer interaction.
A
|
|
V
DBUS for IPC. When programming your app. you might never touch or need to know how to program the Dbus API, everything will be easier and faster. Dbus communication will be Decibel job.
In resume, This framework / API's will accelerate the development of many many new high end class state of the art applications. xD
That's all.. I think xD
> What you describe here is an "easier DCOP", another interface that developers
> will have to add to their programs. Why not spending the effort making DCOP easier...?
That's like saying.. protocols like SMTP / HTTP / FTP are just "easier TCP". Why not spending to effort making TCP easier?
DBus is the communication channel, just like TCP in my example. Over this channel you need to define some message formats. That's one part of what Decibel is going here, defining the messages! Just like SMTP / HTTP / FTP define what messages to send over TCP. Just like Telepathy is doing, like KIMIface does.
Ok, so I think I understand the idea of Decibel, and I think I understand Phonon, so I'll lay out what I think would be a neat scenario, and people who know better than me can say if it will or won't work.
Let's say Phonon and Decibel become relatively well integrated, with the idea that there is a coherent connection between your identity as someone who is communication, and the sounds you are listening to.
Could you:
- Use Decibel as an output for Phonon, allowing any audio application to stream music to any of your "contacts"?
- Use Decibel as an input for Phonon, allowing your contacts to effect what you are listening to?
(There is a gray area of authentication that would need to be addressed for these to become a reality)
In both of these cases, these are things that can be done today, but it seems to me that this would enable them to be done at a much higher level. So rather than audio applications having to deal with network protocols, or network applications having to deal with sound formats, you could have it all helpfully abstracted through Decibel and Phonon). If you wanted to have your audio networked, all you would need is this integration, rather than a plugin for your specific audio program.
I'm sure this isn't the primary focus of these libraries, but I would be very interested to hear how possible this would be.
Thanks.
I don't think it will work quite like that. I think it would be more like
Friend (sends MP3) --> Kopete --> Phonon --> backend of choice (say Gstreamer) --> ALSA --> speakers
However Decibel Amarok Devs may be able to use Decible to give Amarok internal functions for streaming MP3's over VOIP or Instant messenging. I'm not sure about that though.
So KDE4 will integrate firefly and other streaming servers?
well, aside from decibel not really being input to phonon (it's more like it tells phonon to do stuff, and asks for stuff) i guess those things would be possible, yes.
the first example would go more like this (i think):
amarok uses decibel to ask for contacts it can stream music to. decibel only returns those who have the right technology (eg msn can't stream music, so msn-only contacts won't show up. and someone who is offline won't show up either...).
remember phonon doesn't do anything, apps use it. the same with decibel.
and the second:
amarok could have a plugin, which asks decibel to return the 'orders' from the contacts, and amarok will play it (through phonon, indeed).
When will development versions of the next KDE be available?
They are already.
http://kubuntu.org/announcements/kde4-3.80.2.php
http://en.opensuse.org/KDE
http://forums.gentoo.org/viewtopic-t-530111-highlight-kde4.html
etc.
http://developer.kde.org/source/anonsvn.html shows how to get the latest code.
Derek
I don't think he wants to know about 3.80.2, but rather about the NEXT release. I think many want to know... besides a roadmap would be nice.
A tip for the next articles about KDE4 applications/pillars/etc is to mention how far these applications are in the development process.
How is Decibel related to Telepathy. Do these technologies compete or can they use each other?
Decibel uses Telepathy over Qt/DBUS interface.